Hackers Underworld 2: Forbidden Knowledge/Hackers Underworld 2: Forbidden Knowledge.iso/VIRUS/WORM.DOC

Text File | 1994-07-17 | 45KB | 751 lines

Ok dudes, grabed this of a CD-ROM disk of articles, explains how the internet
worm worked.
            Chamelion

Journal:   Communications of the ACM  June 1989  v32 n6 p678(10)

Title:     Crisis and aftermath. (the Internet worm)
Author:    Spafford, Eugene H.

Summary:   The Internet computer network was attacked on Nov 2, 1988, by a
computer worm.  Although the program affected only Sun Microsystems Sun-3
workstations and VAX computers running a variant of version 4 of the Berkeley
Unix, the program spread over a huge section of the network.  Early the
following day a number of methods for containing and eradicating the virus
had been discovered and published.  It was discovered that the worm exploited
flaws in the Unix operating system's security routines and used some of
Unix's own utilities to propagate itself.  A complete description of the
workings of the worm and its methods of entry into Unix systems are
discussed.  The aftermath of the infection and the motives of Robert T.
Morris, its author, are also discussed.

Full Text:

Crisis and Aftermath On the evening of November 2, 1988 the Internet came
under attack from within.  Sometime after 5 p.m., a program was executed on
one or more hosts connected to the Internet.  That program collected host,
network, and user information, then used that information to break into other
machines using flaws present in those systems' software.  After breaking in,
the program would replicate itself and the replica would attempt to infect
other systems in the same manner.

Although the program would only infect Sun Micro-systems' Sun 3 systems and
VAX computers running variants of 4 BSD UNIX, the program spread quickly, as
did the confusion and consternation of system administrators and users as
they discovered the invasion of their systems.  The scope of the break-ins
came as a great surprise to almost everyone, despite the fact that UNIX has
long been known to have some security weaknesses (cf. [4, 12, 13]).

The program was mysterious to users at sites where it appeared. Unusual files
were left in the /usr/tmp directories of some machines, and strange messages
appeared in the log files of some of the utilities, such as the sendmail mail
handling agent.  The most noticeable effect, however, was that systems became
more and more loaded with running processes as they became repeatedly
infected. As time went on, some of these machines bacame so loaded that they
were unable to continue any processing; some machines failed completely when
their swap space or process tables were exhausted.

By early Thursday morning, November 3, personnel at the University of
California at Berkeley and Massachusetts Institute of Technology (MIT) had
"captured" copies of the program and began to analyze it. People at other
sites also began to study the program and were developing methods of
eradicating it.  A common fear was that the program was somehow tampering
with system resources in a way that could not be readily detected--that while
a cure was being sought, system files were being altered or information
destroyed.  By 5 a.m. Thursday morning, less than 12 hours after the program
was first discovered on the network, the Computer Systems Research Group at
Berkeley had developed an interim set of steps to halt its spread. This
included a preliminary patch to the sendmail mail agent.  The suggestions
were published in mailing lists and on the Usenet, although their spread was
hampered by systems disconnecting from the Internet to attempt a
"quarantine."

By about 9 p.m. Thursday, another simple, effective method of stopping the
invading program, without altering system utilities, was discovered at Purdue
and also widely published.  Software patches were posted by the Berkeley
group at the same time to mend all the flaws that enabled the program to
invade systems.  All that remained was to analyze the code that caused the
problems and discover who had unleashed the worm--and why.  In the weeks that
followed, other well-publicized computer break-ins occurred and a number of
debates began about how to deal with the individuals staging these invasions.
There was also much discussion on the future roles of networks and security.
Due to the complexity of the topics, conclusions drawn from these discussions
may be some time in coming.  The on-going debate should be of interest to
computer professionasl everywhere, however.

HOW THE WORM OPERATED

The worm took advantage of some flaws in standard software installed on many
UNIX systems.  It also took advantage of a mechanism used to simplify the
sharing of resources in local area networks.  Specific patches for these
flaws have been widely circulated in days since the worm program attached the
Internet.

Fingerd

The finger program is a utility that allows users to obtain information about
other users.  It is usually used to identify the full name or login name of a
user, whether or not a user is currently logged in, and possibly other
information about the person such as telephone numbers where he or she can be
reached.  The fingerd program is intended to run as a daemon, or background
process, to service remote requests using the finger protocol.  This daemon
program accepts connections from remote programs, reads a single line of
input, and then sends back output matching the received request.

The bug exploited to break fingerd involved overrunning the buffer the daemon
used for input.  The standard C language I/O library has a few routines that
read input without checking for bounds on the buffer involved.  In
particular, the gets call takes input to a buffer without doing any bounds
checking; this was the call exploited by the worm.  As will be explained
later, the input overran the buffer allocated for it and rewrote the stack
frame thus altering the behavior of the program.

The gets routine is not the only routine with this flaw.  There is a whole
family of routines in the C library that may also overrun buffers when
decoding input or formatting output unless the user explicitly specifies
limits on the number of characters to be converted.  Although experienced C
programmers are aware of the problems with these routines, they continue to
use them.  Worse, their format is in some sense codified not only by
historical inclusion in UNIX and the C language, but more formally in the
forthcoming ANSI language standard for C.  The hazard with these calls is
that any network server or privileged program using them may possibly be
compromised by careful precalculation of the (in)appropriate input.

Interestingly, at least two long-standing flaws based on this underlying
problem have recently been discovered in standard BSD UNIX commands.  Program
audits by various individuals have revealed other potential problems, and
many patches have been circulated since November to deal with these flaws.
Unfortunately, the library routines will continue to be used, and as our
memory of this incident fades, new flaws may be introduced with their use.

Sendmail

The sendmail program is a mailer designed to route mail in a heterogeneous
internetwork.  The program operates in a number of modes, but the one
exploited by the worm involves the mailer operating as a daemon (background)
process.  In this mode, the program is "listening" on a TCP port (#25) for
attempts to deliver mail using the standard Internet protocol, SMTP (Simple
Mail Transfer Protocol).  When such an attempt is detected, the daemon enters
into a dialog with the remote mailer to determine sender, recipient, delivery
instructions, and message contents.

The bug exploited in sendmail had to do with functionality provided by a
debugging option in the code.  The worm would issue the DEBUG command to
sendmail and then specify a set of commands instead of a user address.  In
normal operation, this is not allowed, but it is present in the debugging
code to allow testers to verify that mail is arriving at a particular site
without the need to invoke the address resolution routines.  By usin